home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / applic / ntp / doc / info2.txt.Z / info2.txt
Encoding:
Text File  |  1991-09-29  |  7.0 KB  |  180 lines
  1. This is a rough compilation from mail messages I've sent giving advice
  2. about configuring a site.  It has appeared in even rougher form as the
  3. "ntpinfo" file on louie.udel.edu.
  4.  
  5. Last edited on 7 May 1990.
  6.  
  7.     - Cary Gray
  8.       gray@pescadero.stanford.edu
  9.  
  10. --------------------------
  11. [1] one description of configuration
  12.  
  13. Here's the approach I suggest, which maximizes redundancy while
  14. minimizing extraneous traffic.  It also keeps you from ganging up on
  15. any one server.
  16.  
  17. Pick three local hosts to be your campus servers.
  18. Pick six stratum-1 hosts, and pair them off.  For each pair, pick an
  19. external stratum-2 that syncs with primaries other than that pair.
  20. Each of your local servers is then configured as
  21.     peer stratum-1-from-a-pair
  22.     peer other-stratum-1-in-the-pair
  23.     peer corresponding-stratum-2
  24.     peer another-of-the-local-servers
  25.     peer the-third-local-server
  26.  
  27. This is an extremely robust configuration.  The second stratum-1 in
  28. each pair can be farther away (as the packets fly), since the traffic
  29. will normally be light.  It is more resistant to falsetickers and
  30. generates less traffic than having multiple machines all talking to the
  31. same set of external peers.
  32.  
  33. (By "external" I mean outside your organization/site--not one of the
  34. three you're configuring.
  35.  
  36. The external stratum-2 should provide your host a path to two
  37. stratum-1 hosts in addition to those it talks to directly.  If you're
  38. dealing with the public stratum-2 fuzzballs, that's pretty well
  39. guaranteed, since each of them squawks with lots of primaries.  When
  40. you're dealing with other stratum-2 machines, you can get the info from
  41. their keeper--who you want to keep in touch with, anyway.)
  42.  
  43. The remainder of your larger machines can sync from your three
  44. stratum-2s; the rest can just peer with a pair of stratum-3s.
  45.  
  46. For example, kermit.stanford.edu's configuration looks like this:
  47.  
  48.   peer clepsydra.dec.com
  49.   peer ncarfuzz.ucar.edu
  50.   peer holmes.lcs.mit.edu    # by arrangement
  51.   peer neon.stanford.edu
  52.   peer ahwahnee.stanford.edu
  53.  
  54. Holmes squawks with three stratum-1 servers:  bitsy.mit.edu,
  55. umd1.umd.edu, and suzuki.ccie.utoronto.edu.  With holmes, neon,
  56. and ahwahnee-doda, kermit is just two hops away from 7 different radio
  57. clocks should both clepsydra and ncarfuzz go south.
  58.  
  59. My others aren't quite so lovely.  Ahwahnee's primaries are wwvb.isi.edu
  60. and truechimer.cso.uiuc.edu, and its external stratum-2, 
  61. lilben.tn.cornell.edu, does talk to truechimer along with a couple of 
  62. other primaries.
  63.  
  64. If you want to learn about peer sets on machines that don't answer
  65. ntpdc--fuzzballs and host running xntpd--grab the 'ntpq' program from
  66. the xntpd distribution.
  67.  
  68. ------------------
  69. [2] another description
  70.  
  71. You probably want three levels in your configuration.  Here's the way I've 
  72. set it, which gives a lot of redundancy, but without generating a lot of 
  73. traffic.
  74.  
  75. (1) Campus primaries
  76.  
  77. These talk to the outside world; you'll want two or three of these.
  78. If you have three (A, B, and C), the configuration for A should look
  79. like this:
  80.  
  81.     peer first-stratum-1
  82.     peer second-statum-1
  83.     peer external-stratum-2
  84.     peer B
  85.     peer C
  86.  
  87. B and C should be similar, but with different outside hosts.  Also, you
  88. should make sure that 'external-stratum-2' talks to at least two
  89. stratum-1 hosts other than 'first-stratum-1' and 'second-stratum-1'.
  90.  
  91. If you're a small site, you might just two of these machines, in which
  92. case you probably want three stratum-1's each.  (If you're really small or 
  93. rather distant from the backbone, you might want to team up with another 
  94. nearby site (or sites) to bring in three or four stratum-2s; then add another
  95. level or half-level at your site.)
  96.  
  97. A note on picking statum-1's:  give each of your hosts one that is
  98. "nearby" (as the packets fly), with its others spread around.
  99.  
  100. (2) Secondaries
  101.  
  102. You want a pair of these per group of hosts, where a group is easily
  103. upt to 60 or so.  Each should peer with all of the local primaries,
  104. with its partner, and with a secondary in a another group.  For
  105. example, if the pair for a group are X and Y, then X would have
  106.  
  107.     peer A
  108.     peer B
  109.     peer C
  110.     peer Y
  111.     peer a-secondary-in-a-different-group
  112.  
  113. As general rule, X and Y's outher secondaries shoudl come from
  114. different groups.
  115.  
  116. (3) End systems
  117.  
  118. Someday multicast will handle this level automatically.  In the
  119. meantime, the remaining systems in the group with X and Y just need
  120.  
  121.     peer X
  122.     peer Y
  123.  
  124. Some general notes:
  125.  
  126. Using "server" instead of "peer" has two results:  the named host won't
  127. synch to you, and it won't keep track of you either.  The latter makes
  128. it polite when you're banging on a machine that has lots of other hosts
  129. chiming with it, as do most stratum-1 hosts.  At one time that mattered,
  130. but the implementations have been improved; the consensus now favors using
  131. "peer" (almost) everywhere.
  132.  
  133. There are also two differences between "peer" and "passive".  First, if
  134. you configure "passive", your host won't send out packets to the other
  135. unless it hears from it first. So you can use it to cut down traffic if
  136. one machine out of a pair is down a lot.
  137.  
  138. The other difference comes into play only when you configure a server
  139. with "trusting no".  It then will synch only to hosts mentioned in the
  140. configuration file:  one's you trust can then be named as passive.
  141. (I've made my local primaries non-trusting because some other folks
  142. peering with the public one have really brain-damaged configurations
  143. that could otherwise confuse false-ticker detection.)
  144.  
  145. ----------------
  146. [3] configuring ntpd for a reference clock
  147.  
  148. ... [from a message to someone on the west coast] 
  149. ... You'll still need to pick external peers, both
  150. stratum-1 and -2.  pub/ntp/clock.txt on louie.udel.edu lists a number
  151. of public servers.  I think you'll do well with all of the good
  152. west-coast primaries:  wwvb.isi.edu, fuzz.sdsc.edu, and
  153. clepsydra.dec.com (which is here in Palo Alto).  You'll also probably
  154. do well with the other fuzzballs on the NSFnet backbone, which are
  155. listed in clock.txt.  I can offer stratum-2 from here at Stanford:
  156. kermit.stanford.edu is public, and ahwahnee and neon are
  157. available by arrangement.  My personal advice is to steer clear of the
  158. WWV clocks advertised as stratum-1, since they don't seem to give very
  159. stable time, and the three I'm aware of near me (apple.com,
  160. hp850.mbari.org, and norad.arc.nasa.gov) are the reason my hosts have
  161. gone non-trusting.
  162.  
  163. To configure a local clock, you have to compile in the reference clock 
  164. support, and put something like this into your ntp.conf:
  165.  
  166.     peer /device reference-id stratum precision type
  167.  
  168. For the system clock, /device just needs to start with a "/" (it would
  169. be a tty line if using a radio clock), and type is "local".  Precision
  170. is the same as configured (-7 on vaxen), and stratum is whatever you
  171. want, e.g., 6.  I'm not sure what the blessed name for reference-id
  172. is---up to four characters, maybe SYS?  So that comes out looking like
  173.  
  174.     peer /dev.null unix 6 -7 local
  175.  
  176. If you do this, keep the stratum pretty high (> 5) so that you don't confuse 
  177. anyone.  If you want to order a set of hosts in this manner, increment 
  178. stratum by 2 as you head down the ranking.
  179.  
  180.